-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ingesters: Delete blocks relative to when they were uploaded to storage #3816
Conversation
0b10001
to
931fa26
Compare
Have you considered making it based on when the block is created? You can read the creation timestamp from the block ULID. |
@pracucci ULID can give me that information but I actually need to know it was shipped because I have to wait until its shipped and re-scanned. I can now know the first part with this implementation and I can have an estimation as a constant for the second part. If I did it relative to block creation time maybe its shipped late for whatever reason i.e errors uploading to gcs, and whenever it got uploaded it could also get deleted. If this happened there could be a time there were data disappears for queries until blocks are re-scanned by the store gateways. |
1c16137
to
650bfb6
Compare
I think that doing it based on shipping time is safer: in most case it will be the same, but as @jesusvazquez mentions, in case of a block storage outage for whatever reason, we'll keep the block for enough time. |
122d5df
to
df06de9
Compare
Since this changes the mental model of how blocks are managed on ingesters, please make sure you update any relevant docs and runbooks. |
76311a3
to
31bf115
Compare
Hey @56quarters, I updated the docs and the reference help as well as added an entry in the CHANGELOG and updated the description of the Do you know of any other doc pointers I should update? In the meantime I'll set this PR as ready to review. |
This looks good to me, also the change makes a lot of sense. I did some pair programming on this though, so we'd need an approval from someone who's not me. |
Shipping is an optional feature, and there are users who run Mimir with shipping disabled. Is that case properly handled by the PR? (Just started the review) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I don't see above-mentioned case when shipping is disabled handled in the PR. With shipping disabled, perhaps we can check block creation time against the "deadline".
I'd also suggest adding test for "shipping disabled" case.
bd8958f
to
397640f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, PR looks good to me. I've left some non-blocking comments.
@@ -233,41 +230,63 @@ func (s *Shipper) blockMetasFromOldest() (metas []*metadata.Meta, _ error) { | |||
return metas, nil | |||
} | |||
|
|||
func readShippedBlocks(dir string) (map[ulid.ULID]struct{}, error) { | |||
func readShippedBlocks(dir string) (map[ulid.ULID]time.Time, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] We can simplify shipper code a bit if we return map[ulid.ULID]model.Time
here.
5124791
to
40ff081
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much!
40ff081
to
ed76885
Compare
Thank you for the reviews @pstibrany !! 🎉 |
pkg/ingester/shipper.go
Outdated
} | ||
|
||
// Keep backwards compatibility with the previous Mimir version. | ||
// TODO Remove in Mimir 2.7.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please replace 2.7 with 2.8 across the file. We'll announce in 2.6, so we can remove starting 2.8.
ed76885
to
ce92779
Compare
This commit changes the logic of when blocks will be deleted on ingesters. Before it was relative to the newest block for the tenant minus a certain retention. Now it depends on whether or not shipping is enabled. - If it is enabled, deletion will be relative to when the block was uploaded minus a certain retention. - If it is disabled, deletion will be relative to when the block was created minos a certain retention. We do this for two reasons: - It will allow us to lower the retention on ingesters making them ligther. - If the out-of-order window is bigger than the retention time, with the previous logic blocks would be deleted right after upload, leaving a time where data would not be queryable. Signed-off-by: Jesus Vazquez <jesus.vazquez@grafana.com>
ce92779
to
00a3516
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job! LGTM 👏
Signed-off-by: Jesus Vazquez <jesus.vazquez@grafana.com>
Signed-off-by: Jesus Vazquez <jesus.vazquez@grafana.com>
c2360b6
to
26be232
Compare
This PR changes the logic of when blocks will be deleted on
ingesters. Before it was relative to the newest block for the tenant
minus a certain retention. Now it depends on whether or not shipping is
enabled.
uploaded minus a certain retention.
created minos a certain retention.
We do this for two reasons:
ligther.
previous logic blocks would be deleted right after upload, leaving a
time where data would not be queryable.